This paper observes that a significant problem to use of computers in the arts is a lack of what the author calls "middleware". (I would add to this that no appropriate ontology exists for sharing of programmed modules.)
They are exploring the use of ubiquitous computing in the arts.
They make the observation that high-level multimedia programming environments like Director, Max/MSP, and Visual basic are available but lack a consistent interface to the external world.
They refute two ideas or myths in order to make a point:
1. The myth of interface independence. Transparency is not irrelevance. This is a controversial point that I don't particularly agree with (itŐs a bit like throwing out the baby with the bathwater). They make the point that when interfaces are generalized they tend to be toward a lowest common denominator. They make the point that when someone learns something well enough they cease to be aware of it. The observation is that these particular physical properties of interface or environment are part of the user experience that is critical to their ability to disappear.
I think the argument here is flawed because it fails to recognize the idea of enhancement of generalized devices through inheritance, and the benefit of shielding users from unnecessary details.
I think what the authors are trying to point out is that there needs to be a mechanism for allowing the user to get at the devices to expand program capabilities. An interface between the high level application and the low level devices that is easy to understand and use.
A useful quote recognizing the issues around proprietary interfaces not being able to be expanded to new devices without technical knowledge.
Can
there be middleware that consistently and simply exposes the specific
functionality of devices on a network to artists, even if it is part of a
larger, task-oriented infrastructure with other, more abstract interfaces? Or,
will this type of control remain in the domain of specialized scripting
languages and inflexible, hermetically sealed control systems interconnected by
proprietary interfaces?
2. Authoring come for free. This I agree is a myth. They make the observation that in many cases in ubiquitous computing that the applications for experimentation, toolkits etc tend to be domain-specific.
Two useful quotes about collaborations and the creative process:
For
the foreseeable future, these collaborators must have some technical expertise
among them, but it should be focused on understanding technological
affordances, and developing the relationships and media of an experience,
rather than on the details of device interfaces or networking.
At
this time, though, it seems that the choices of authoring systems either
isolate the author completely from devices or remain too low-level for
non-programmers.
Requirements:
1. ability to meet a deadline.
2. flexible and resilient.
3. traditional and non-traditional input and output devices must be supported.
Design goals
1. simple, consistent, and expressive scripting language for authors.
2. stable
3. soft real-time performance.
4. grouping and synchronization are necessary.
The authors note that they have soft real-time" requirements. I view this as hard real-time because a failure in the presentation to the audience removes them from suspension of disbelief, resulting in a failing system.
Knom model:
Knobs: physical and virtual entities. organized in a tree structure referenced from a pathname starting at the root.
Knats are leaf nodes that take on values for whatever is being represented. This is the manifestation of the abstract thing (the knob i guess).
Subscription. Knobs and Knats can "subscribe" to another nodes value and take action based on the value.
Arbitration. If more than one node (a knat or knob) competes for control of something, an arbitrator figures it out.
Implementation:
uses Java and distributed communication through TCP/IP. Communication occurs through UDP, SOAP over TCP for control. They hope that the use of SOAP will facilitate the creation of a web service description language to describe knob and knat functionality.